\section{Synopsis}\label{sec:summary}
The aim of this section is to describe the main functionality of Polkadot without going into details about the design considerations and reasoning.
% Please keep this 2 pages or less.

The Polkadot system consists of a single open collaborative decentralised network called the relay chain, that interacts with many other external chains run in parallel called \emph{parachains}. From a high-level perspective, parachains are clients of the relay chain, which provides a security service to these clients, including secure communication. That is the sole purpose of the relay chain; parachains are the entities providing application-level functionality, such as cryptocurrencies.

The internal details of parachains are not a concern of the relay chain; parachains need only adhere to the interface we specify. Some of these expectations are natural components of blockchains, hence the naming. However, other non-blockchain systems may also run as a Polkadot parachain as long as they satisfy the interface. This is described below: relevant parts are \uline{underlined}.

These aspects may be abbreviated as, \emph{Polkadot is a scalable heterogeneous multi-chain}.

\subsection{Security model}

We assume that parachains are running as external untrusted clients of the relay chain and that the relay chain only deals with parachains via an interface and does not make assumptions about their internals. For example, internally they may be permissioned or open; if some internal users subvert the parachain, from Polkadot's viewpoint the entire parachain (as a single client entity) is malicious.

The Polkadot relay chain is designed to deal with a level of malicious behaviour internally, as a requirement of being an open decentralised network. Specific individual nodes are untrusted, but an indeterminable subset of nodes lower-bounded in size are trusted, and the protocol works to ensure that the relay chain externally as a whole is trustable. See section \ref{sec:security_model} for details.

\subsection{Nodes and roles}

The Polkadot relay chain network consists of nodes and roles. Nodes are the network-level entities physically executing the Polkadot software, and roles (Section \ref{sec:roles}) are protocol-level entities performing a particular purpose. Nodes may perform multiple roles.

On the network level, the relay chain is open. Any node may run the software and participate as any of these types of nodes:

\begin{enumerate}
\item Light client - retrieves certain user-relevant data from the network. The availability of light clients is irrelevant - they don't perform a service for others.
\item Full node - retrieves all types of data, stores it long-term, and propagates it to others. Must be highly available.
Sometimes we refer to a \emph{full node} of a parachain. In the abstract sense for non-blockchain parachains, this means that they participate in it to a sufficient degree that they can verify all data passing through it.
\end{enumerate}

Beyond distributing data, relay-chain nodes may perform certain protocol-level roles listed next. Some of these roles have restrictions and conditions associated with them:

\begin{enumerate}
\item Validator - performs the bulk of the security work. Must be a full node of the relay chain. Interacts with parachain collators, but need not participate in a parachain as a full node. %When validators are assigned to parachains they are called \emph{parachain validators}.
\item Nominator - stakeholder who backs and selects validator candidates (Section \ref{sec:validators}). This can be done from a light client, and they need not have any awareness of parachains.
\end{enumerate}

Parachains may decide their own internal network structure, \uline{but are expected to interact with Polkadot via the following roles}:

\begin{enumerate}
\item Collator\footnotemark[1] - collects and submits parachain data to the relay chain, subject to protocol rules described below. They are chosen as defined by the parachain, and must be full nodes of it.
\item Fishermen - performs additional security checks on the correct operation of the parachain, on behalf of the relay chain who supplies a reward. This role is self-assigned and reward-incentivized, and must be a full node of the parachain.
\end{enumerate}

\footnotetext[1]{Validators are in some sense a collator of the relay chain network, in that they collect extrinsics (e.g. transactions) within the relay chain network. However we typically only refer to them as validators even when performing these tasks, and the term \emph{collator} is reserved for parachain collators only.}

\subsection{Protocol}

The Polkadot relay chain protocol, including interaction with parachains, works as follows.

\begin{enumerate}
\item For each parachain:

  \begin{enumerate}
    \item \uline{Collators watch the progress of the block-producing and consensus protocols}, steps (2) and (5) respectively below, e.g. by participating in the relay chain as a full node. Based on what they think is the latest relay chain block that will most likely be finalised, they build on top of the latest parachain block (or other data) that would be finalised by it.
    \item \uline{Collators sign data building on top of said latest parachain block, and submit it possibly indirectly}, to the validators assigned to their parachain (\emph{parachain validators} for short), for inclusion in the relay chain. Ideally they submit a unique one, to help performance.
    \item The parachain validators decide which parachain block to support, and presents relevant data of it as a parachain's next \emph{candidate} to be added to the next relay chain block.
  \end{enumerate}

\item A block-producing validator collects candidates from all parachains, and puts this collection along with any recent relay chain extrinsics into a relay chain head block. (Section \ref{sec:babe}). For performance, this does not contain the full data from all parachains, but only metadata and partial data, including security-related metadata.

In the unfavourable case, this can result in forks, resolved later in step (5). This subprotocol is designed so that even with forks, participants have an idea of the block most likely to be finalised, similar to Proof-of-Work protocols.

\item A subprotocol is run to ensure that the full data is indeed available, including and distributing it to various other relay-chain nodes. (Section \ref{sec:validity-and-availability}).

\item Data submitted from a parachain might include indications that they are sending messages to another parachain, including metadata to facilitate this. This is now included on the relay chain head(s), so recipient parachains are aware of which new messages have been sent to them. \uline{They now retrieve the message bodies from the sending parachains}. (Section \ref{sec:XCMP}).

\item Validators submit their votes on the block and finalises it, resolving any forks to a single head. (Section \ref{sec:grandpa}). These votes are added to the relay chain blocks.

\end{enumerate}

% There is a small section on bridges in the Appendix, suggesting that it is just initial ideas at the moment. It can be summarised here later, once we turn it into a proper first-level section.

The rest of the paper expands on the above - roles next in Section \ref{sec:preliminaries}, and protocol subcomponents in Section \ref{sec:components}.
